Overload or congestion control is one of the key mechanisms to accommodate the increasingly diverse range of services and types of traffic in the Internet. As commonly known, TCP is the most popular transport layer protocol for data transfer. It provides connection-oriented reliable transfer of data between two connecting hosts, wherein a host refers to a network-connected computer or to any system which can be connected to a network for offering services to another host connected to the same network. TCP uses several techniques to maximize the performance of the connection by monitoring different variables relating to the connection. For example, TCP includes an internal algorithm for avoiding congestion.
Congestion control relates to the general problem of traffic management for packet-switched networks. Congestion means a situation in which the number of transmission requests at a specific time exceeds the transmission capacity at a certain network point (called a bottle-neck resource). Congestion usually results in overload conditions. As a result, the buffers may overflow, for instance, so that packets are retransmitted either by the network or by the subscriber. In general, congestion arises, when the incoming traffic to a specific link is more than the outgoing link capacity. The primary function of congestion control is to ensure good throughput and delay performance while maintaining a fair allocation of network resources to the users. For the TCP traffic, whose traffic patterns are often highly bursty, connection control poses a challenging problem. It is known that packet losses result in a significant degradation in TCP throughput. Thus, for the best possible throughput, a minimum number of packet losses should occur.
Currently, several schemes, including Fast-TCP, have been put forward to enhance the function of avoiding congestion in the TCP flow control. Although the purpose of these mechanisms is to avoid packet droppings in case of queue overflows, network congestion cannot be completely avoided even with very perfect congestion avoidance mechanisms. Thus, it is still necessary to combine these mechanisms with existing TCP flow control mechanisms for congestion control, that is, source window reduction shall sometimes be invoked by lost packets due to a buffer overflow, to thereby alleviate the congestion in time.
Initially, the Internet was intended to support best-effort service, and the TCP congestion control method that was actually implemented has been developed on the assumption that the network would be treated as a black box. This means that the end nodes do not exercise control by directly ascertaining the state of routers and transmission lines, but rather regulate the traffic by inferring the network load indirectly from packet loss and response time fluctuations. In wired networks, this may not induce serious problems, as packet losses mainly occur due to congestion. However, in the presence of high error rates and intermittent connective characteristic as in wireless links, this reliance on packet drops as an indicator of congestion causes a significant degradation in TCP performance, since the TCP reacts to packet losses as it would in the wired environment. Namely, it drops its retransmit window size before retransmitting packets, initiates congestion control or avoidance mechanisms and resets its retransmission timer. This results in an unnecessary reduction in the link bandwidth utilization of wireless and mobile networks, causing poor throughput and very high interactive delays.
Recently, several schemes have been proposed to alleviate the effects of non-congestion-related losses on TCP performance over networks that have wireless or similar high-loss links.
In the article “Implementation and Performance Evaluation of Indirect TCP” by Ajay V. Bakre et al, IEEE Transactions on computers, Vol. 46, No. 3, March 1997, the Indirect-TCP protocol is described as one of the first protocols to distinguish different losses by splitting a TCP connection between a fixed and a mobile host into two separate connections at the base station, such that a more optimized wireless link-specific protocol tuned for better performance can be used over a one-hop wireless link. However, there are some drawbacks of this approach, such as loss of semantics, application re-linking and software overhead.
Furthermore, an ELN (Explicit Loss Notification) protocol has been proposed, wherein an explicit loss notification option is added to TCP acknowledgments, when a packet is dropped on the wireless link. In this case, future cumulative acknowledgments corresponding to each lost packet must always be marked to identify that a non-congestion-related loss has occurred. Moreover, it might be difficult to identify packets lost due to errors on lossy links and to determine a connection of a corrupted packet, since the header could itself be corrupted.
Additionally, another research area is described in “A proposal to add Explicit Congestion Notification (ECN) to IP” by K.K. Ramakrishnan et al, Internet Draft-kksjf-ecn-02.txt, September 1998, wherein congestion control is decoupled from packet loss. By doing this, packet losses will not invoke congestion control, such that transmission errors do not lead to a reduced throughput. In particular, an Explicit Congestion Notification (ECN) is added to a TCP acknowledgment option by detecting incipient congestion in the network. Upon receiving this ECN message, the transmitter reduces its congestion window whenever a loss occurs.
However, many current networks with routers whose main function is to route packets have no provision for the detection of an incipient congestion before a queue overflow occurs. Nevertheless, even if such a provision were provided, the packet marking rate could not catch up with its passing rate during periods where the average queue size exceeds an upper threshold. Therefore, routers drop packets rather than setting the ECN in the packet header.
In spite of all these difficulties, ECN is likely to be adopted gradually. Thus, accommodating migration is an essential requirement for future TCP networks.
As an indication of congestion when the buffer had not yet overflown, an ECN bit is set in the packet header when it arrives at the input port. Then, it is routed towards its destination. At the destination, the ECN bit is set in the next outgoing ACK (acknowledgment) packet and is returned by the receiving terminal to the source. Although it can be implemented in any asymmetric network node with a function of avoiding congestion, packet losses due to congestion will not be completely prevented, since the network conditions are complex and it is always difficult to grasp the extend to which the network will be congested. Moreover, due to the incremental development of the ECN mechanism and in order to overcome exceptions in normal ECN environments, it is required to combine the ECN scheme with existing TCP mechanisms for congestion control.
In the presence of high error rates and intermittent connective characteristics of wireless links, this entirely (TCP congestion control mechanism) or partly (ECN mechanism) reliance on packet losses to initiate congestion control results in an unnecessary reduction in the link bandwidth utilization, since packet losses not mainly occur due to congestion. To prevent packet losses irrelevant to congestion from initiating congestion control, a Wireless-ECN (WECN) message was proposed to be added just upon the occurrence of a first packet loss due to buffer overflow in a network node. Due to asymmetric considerations, a CE bit of the IP header, which is set in the intermediate network nodes, needs to be extracted and a WECN flag needs to be added at the receiver side, such that the control loop is the same as in the ECN mechanism. Compared to ECN, WECN acts in a more simple and unit way, since the complexity and inconsistency of buffer management in the networks and the more conservative TCP congestion control over a short-scale period at the source side, which are required in the ECN mechanism, are avoided. As it is very easy for WECN to be suited to any congestion control mechanisms, TCP congestion control mechanisms can get completely independent of retransmissioned strategies whether they have complete or part relation to lost packets, and high performance in wireless and mobile networks will invariably be obtained with the addition of this mechanism.
However, in the above TCP congestion control mechanisms, whenever the congestion control is performed before or after congestion, two common features exist. Firstly, the congestion control algorithm is implemented at the source terminal, and, secondly, the message used to indicate congestion and to invoke source window reduction must be forwarded from the receiver side. This leads to the following problems.
As the source window decreases very sharply and quickly at the threshold point, the buffers following the change in the window size in the network are not fully utilized and also oscillate very frequently with the result of low throughput and degraded performance. When the upper bound of the queue length is higher than the buffer threshold, a CE bit suggesting a reduced rate limit is set in the network node and must first be sent to the receiver, and then returned back to the controllable source. Thus, the source has to wait a round-trip time before receiving a response to the ECN messages. This long feedback delay of ECN messages causes low buffer utilization and a requirement of large buffer sizes.